home *** CD-ROM | disk | FTP | other *** search
- Usage of Color Maps in GIF, and Recommendations (V 2.0)
-
- by Larry Brennan, 73327,3452
-
- Since an update of the GIF87a is contemplated, and some recent msgs on
- the Board have indicated misunderstandings of the significance of the
- Global Header information described as CR ( color resolution ) and Pixel,
- please indulge me in my attempt to clarify. Then I'll recommend a slight
- change in the Standard and several changes in the practices of encoding
- and decoding GIF messages. The purpose is to increase the information
- content of the data, while reducing the redundant content of the message.
-
- The CR value represents the information value of the originator's
- selection of colors to represent the subject, as limited by the originator's
- machine and choice of mode. The originator might have a choice field of,
- say, 64d (EGA), or 4Kd (Amiga), or 16Md (VGA), and that information is
- pertinent to the decoder's choices of data for use of the target machine.
- The Pixel information represents the maximum palette array available to
- the originator's machine or mode, also useful information as to the limitations
- of the encoded message.
-
- The 87a definition of Pixel usage unnecessarily requires a color map
- content of the maximum number of available palette indices, whether they
- are used or not, and usage of all of the indices is actually not common
- in practice. I heartily endorse the restriction of color map requirements
- to the actual number used by the originator, with a few usage caveats as
- described below.
-
- The suggested usage refinements suggested are almost all at the encoder
- end of the translation for transmission, so the extra time and effort called
- for is not as critical as at the decoder end, where speed is more valued.
- My first plea is for the elimination of redundant hue choices occupying
- multiple palette indexes ( very common ). The encoder can
- easily do this, and the decode process is simplified. The next step
- would be to substitute NULL (0,0,0 for R,G,B) hue values for any palette indexes
- not actually used. Again a simple encoder process making the decoder's
- life easier ( see CNTGIF & GIFDMP for methods). Next, reassign all used hue
- codes into the lowest palette indexes and delete all NULL values (with two
- exceptions) from the color map. The exceptions are palette index 0, reserved
- for a useable (black) NULL value which also serves as a start delimiter for the
- color map, and another NULL value as an end delimiter for the
- condensed map. Note that the information content is the same as before the
- encoding and reorganization. Now, to increase the useful information content,
- arrange the non-zero hues into palette indexes in reverse order of actual
- employment in the particular frame. The decoder can address the translation
- of the original color map to the target machine's color map in the priority of
- actual usage in this specific frame, with no cost in time and with no clutter
- of either redundant or unused definitions. Note also that existant GIF files
- are still fully decodable without modification.
-
- It is my view that at this point the decoder should carry
- some of the load and eliminate any hue redundancies in the target's map
- after translation, and also reassign the useful hues to the lower palette
- indices. I don't sense a value to ordering the hue assignments by usage
- prevalence, but it would make for a still cleaner end product.
-
- So my recommended changes are quite minimal by themselves, but |+^|result in a cleaner, neater, product which will be more easily upgrade
- for future needs and increase the useful information content of the product
- with little trouble or hassle now, and invisibly to the casual user.
-
- Thanks for the use of the Hall. Larry Brennan.
-
-
-
-
-
-
-